home *** CD-ROM | disk | FTP | other *** search
/ CD Classic / CD CLASSIC #1.iso / 3df / read.me < prev   
Text File  |  1991-04-20  |  7KB  |  175 lines
  1. General
  2.  
  3. 3dF is an extract of TerraBase, a system for
  4. manipulating terrain models.  Several people
  5. expressed an interest in the part that does
  6. real-time orthographic rendering of a piece of
  7. terrain as a `floating net' with hidden lines
  8. removed, so I provide this code and executable
  9. for information and experimentation.
  10.  
  11. It is reasonably fast.  On a 4.77Mhz 8088, it
  12. draws one frame of a 30x30 grid in 2.3 seconds.
  13. On a 16Mhz 80486, it looks like about 4-5 frames
  14. a second; quite smooth.
  15.  
  16. Since most folks will not have terrain data,
  17. I've glued on a front end that accepts an
  18. expression in x and y and calculates f(x,y) to
  19. form the net heights.  The total user interface
  20. is the command line plus the cursor keys that
  21. control the view angle for the orthographic image.
  22. Hence a command line editor is a huge convenience.
  23.  
  24. The result is a very good test and experimentation
  25. base for the surface rendering code and a marginal
  26. F(x,y) sketcher; calculus teachers may find it
  27. useful, for instance.
  28.  
  29. Usage
  30.  
  31. Just type 3DF for a demo.
  32.  
  33. Here is the help, which may also be obtained
  34. with `3DF /?' at the MSDOS prompt.
  35.  
  36. --
  37.  
  38. Usage: 3df [[options] expression]
  39.   options:
  40.     /x<real>    -- x of domain center (default 0)
  41.     /y<real>    -- y of domain center (default 0)
  42.     /s<posReal> -- x and y size of domain (default 1)
  43.     /?          -- This help.
  44.   expression: Optionally "quoted" function of x and y.
  45.     Operators by precedence:
  46.       a^b - a to b power, b >= 0 or int < 0    right associative
  47.       -a  - negate a
  48.       a*b - a times b    a/b - a divided by b  left associative
  49.       a+b - a plus b     a-b - a minus b       left associative
  50.     Functions:
  51.       Sin(a), Cos(a), Ln(a), Exp(a), Sqrt(a), Atan(a), Abs(a),
  52.       Min(a,b), Max(a,b).  Case is ignored.
  53. Example:
  54.   3df /x1 /y1.2 /s2 min(2,sqrt(abs(1-x^2-y^2)))
  55.  
  56. --
  57.  
  58. The optional quotes are to convince shells
  59. that the expression is not something else.  4DOS,
  60. for instance, is upset by the ^ character unless
  61. the formula is quoted.
  62.  
  63. Once the function is calculated and the image is in
  64. view, note the arrow is pointing in the positive y
  65. direction.   The left/right cursor keys affect
  66. rate of rotation about the F axis.  Up and down
  67. increment/decrement the elevation of the view angle.
  68. PgUp and PgDn magnify and shrink along the F axis.
  69. Home sets just the rotation speed back to the small
  70. initial value.  End sets everything, angles and
  71. magnification back to initial values.
  72.  
  73. The Code
  74.  
  75. As noted in the comments, the code is not pretty.
  76. It was written primarily on a dare from someone
  77. who wanted to buy some expensive hardware to do
  78. the same thing as this program; there wasn't much
  79. time to get it done.
  80.  
  81. Those who have the patience to plow through it
  82. will see that the algorithms are really quite
  83. simple; I think the Pascal could be about half
  84. its current size and faster if one were to give
  85. some careful thought to a rewrite.  The assembly
  86. code is pretty tight, but optimized for 8088; there
  87. should be some changes for 803|486.  Again sorry for
  88. the lack of comments.
  89.  
  90. The line-drawing code is a standard Bresenham algorithm
  91. that computes pixel masks and addresses incrementally
  92. rather than computing (x,y)s, then computing a mask and
  93. address for each point.  This makes it faster than most
  94. libraries, the BGI for instance.  The other thing that
  95. helps speed is that there is no clipping or chopping;
  96. the image MUST remain on the screen or the CPU generally
  97. goes to LaLaLand.
  98.  
  99. Lines are written into a 16k buffer, then the buffer is
  100. blasted onto the screen when an image is complete.  This
  101. approach was the only one possible with the CGA, as we
  102. didn't want to watch the drawing in progress.  The copy
  103. requires only 18 milliseconds on my 8088 by a crude
  104. benchmark, and having the buffer be contiguous rather
  105. than in even and odd scan lines makes the line-drawing
  106. code much simpler.
  107.  
  108. The other thing the line code does is hidden line removal.
  109. The Pascal code ensures that the image is drawn `front
  110. to back' no matter what the rotation angle.  That's the
  111. reason for the four copies of the surface heights; it was
  112. easier to make the copies than to fiddle with four different
  113. loop increment schemes depending on the view angle.
  114. (I told you it was nasty code ;-} )
  115.  
  116. Given front to back drawing, all we need is a vector of
  117. 640 words to hold the y of the top-most dot drawn so far
  118. for each x.  Before drawing each dot, we consult the vector
  119. to see if there's already a dot higher (smaller y since y
  120. is 0 at the top of the screen) for that x.  If so, the new
  121. dot is `hidden' and we don't plot it.  If not, its `visible'
  122. so we draw the dot and update the vector.  The area
  123. under (of greater y than) the vector values is considered
  124. to be `the cloud'. You never draw anything on the cloud, only
  125. add to its top fringe.
  126.  
  127. Actually two vectors are necessary to keep track of the
  128. cloud, one with old values and one with new.  As we draw,
  129. the old one is consulted to make the visibility decision
  130. and the new one is updated.  After each row of net squares
  131. is drawn (in some cases between squares), we update the
  132. old cloud with the new one and continue.  Only the stretch
  133. of vector values that were actually changed is copied; this
  134. little optimization improves speed quite a bit.  The
  135. `obvious' improvement of accessing the vectors through
  136. pointers and just swapping pointers as necessary doesn't
  137. pan out when you think about it a bit.
  138.  
  139. There are many, many improvements possible.  The first is
  140. that we're tracking only the top of the cloud, when a more
  141. general approach is to track the top and bottom using four
  142. vectors, and add to both the bottom and top fringe as we
  143. draw.  What would this buy us?  Well, we wouldn't need
  144. the `skirt' along the edges that runs down to the min F
  145. value; we would correctly see visible sections of the
  146. underside of the surface from low view angles.  (If the
  147. skirt weren't there now, visible portions of the underside
  148. would simply be missing.  In fact with this mod there would
  149. be no reason to restrict view angles to be above the x-y
  150. plane.  We could look up from below just as easily as we
  151. now soar above.  Unfortunately this puts a new comparison
  152. and possible vector update in the inner loop, so there will
  153. be significant performance degredation; my guess is 10%.
  154.  
  155. Axes and labels could be added.  You could invent a simple
  156. stroke font or borrow one of Borland's, transform points
  157. the same way as image points, and get orthographically
  158. projected text.  This has to be drawn at the right time;
  159. first if it's in front and last if it's at the back of
  160. the image; and you have to make this decision based
  161. on view angle.
  162.  
  163. A major project would be to add clipping and then perspective
  164. so one could fly over, under, and through the surface.
  165. Clever assembly language hacking should keep it fast. Recall
  166. that flight simulators do it, though they handle smaller
  167. images than our 900+ points and 1800+ line segments.
  168.  
  169. Gene Ressler
  170. ressler@cs.cornell.edu
  171. 124 Pine Tree Road,
  172. Ithaca, NY  14580
  173.  
  174. April 91
  175.